Ethernet Link Monitoring Channel

ABSTRACT

The invention provides a method for utilizing the Inter Packet Gaps (IPGs) to create an Extended Link Monitoring Channel in a physical layer transceiver for a 10 Gb/s Ethernet link for communicating link related information, thus providing an extensive link maintenance capability. A corresponding transceiver between an Ethernet media access control (MAC) layer device and a 10 Gb/s Ethernet link, comprising a physical coding sublayer (PCS) extension circuit for implementing the Extended Link Monitoring Channel is also provided.

RELATED APPLICATIONS

This application is a Continuation of a pending application entitled, ANEXTENDED LINK MONITORING CHANNEL FOR 10 Gb/s ETHERNET, invented byPopescu et al., Ser. No. 10/701,485, filed Nov. 6, 2003, which isincorporated herein by reference.

FIELD OF THE INVENTION

The invention related to Ethernet communications networks, and inparticular, to an extended link monitoring channel for 10 Gb/s Ethernet.

BACKGROUND OF THE INVENTION

The Ethernet Standard (IEEE 802.3) has recently been extended to includeoptical communications links operating at the speed of 10 Gb/s (IEEEDraft P802.3ae 2002). In this application, the IEEE 802.3 standard withits supplements will simply be referred to as the standard, and will beincorporated herein by reference.

For communication links in Local Area Network (LAN) and MetropolitanArea Network (MAN) environments, the new type of links (also known as10GBASE) provides a lower cost alternative to SONET OC192 which hastraditionally been employed for optical communications links to carrypayload data of the order of 10 Gb/s between distant nodes.

Note that the Ethernet Standard IEEE 802.3 describes a number ofvariations of the 10GBASE family of links, combinations of suffixes suchas R, X, S and L, M, and W referring to variants of format and ofoptical characteristics (see clause 44 of the standard). A variant ofinterest in Metropolitan environments is denoted 10GBASE-R (clause 49 ofthe standard). The I OGBASE standard also includes an optional formatfor embedding 10 Gb/s Ethernet signals at a slightly lower bit rate, asa payload within a SONET OC192 signal (10GBASE-W, clause 50 of thestandard). The primary use of 10GBASE-W is in MANs and Wide AreaNetworks (WAN) where SONET is the predominant infrastructure.

While SONET provides for a variety of payload types which may includesynchronous data as well as packet data, the 10GBASE-R links aredesigned to carry Ethernet packets directly, with a much simpleroverhead structure than SONET.

SONET, having originally been developed as a universal optical transportprotocol including long haul, provides a large number of overheadfeatures, many of which may not be needed in a MAN environment,especially in cases where the only payload is packet data.

Ethernet on the other hand, having originally been developed as a LANmedium (and having evolved in speed to 10 Gb/s, and in scope to MAN),lacks some overhead features which may be desirable when used directlyto interconnect nodes in a MAN environment. In many cases, with a packettransport medium, link related messages could be carried in additionalpackets, alongside the packets that carry user data.

This practice has a number of undesirable consequences: packet bandwidththat is used in carrying link related data is not available as userpacket bandwidth; user packets and link related packets aredistinguished only through their packet headers, increasing thepossibility of malfunctions caused by incorrect headers, maliciouspackets, or decoding errors; and it may be difficult to provide accessto the packet stream for the insertion of link related messages at linkends, for example requiring extra buffers and causing unwanted delay.

Another concern is the reduced ability of the Ethernet formats toprovide link maintenance and link supervision features, especially whencompared to such features in SONET. For example, SONET providesextensive bit-error monitoring of links using bit interleaved parity(BIP), and alarms for reporting error conditions from the far end.

A 10GBASE-R link according to the prior art is illustrated in FIG. 1.Shown is a bidirectional 10GBASE-R link system 100 interconnecting atthe physical level two nodes, Node “A” (102) and Node “B” (104). Thesystem comprises two 10GBASE-R transceivers 106 and 108 (commonlyreferred to as physical layer interface, or “PHY”, devices),interconnected by a transmission link 110. The transmission link 110 isalso referred to as a “10 Gb/s Ethernet Link”. Electrical “10 GigabitAttachment Unit Interfaces” (XAUI) 112 and 114 provide access to thelink from other equipment (not shown) in the nodes 102 and 104respectively.

Each of the transceivers 106 and 108 comprises a number of adaptationmodules 116-122 to convert signals between the XAUI interfaces and the10 Gb/s Ethernet Link 110, as well as a control module 124 forcontrolling the modules 116-122 and other devices. The transceivers 106and 108 may also include electro-optical devices which are not shown.

In conformance with the standard, the conversion is done in two stepsthrough intermediate internal interfaces 126 and 128 referred to asXGMII or “10 Gigabit Media Independent Interface”.

The adaptation modules are of two types, “XGMII Extender Sublayer”module types (XGXS) 116 and 118 for converting between XAUI (112, 114)and XGMII (126, 128) in each direction, and “Physical Coding Sublayer”module types (PCS) 120 and 122. For a 10 Gb/s Ethernet Link 110according to the 10GBASE-R standard, the PCS modules 120 and 122 provideconversion in each direction between the XGMIIs (126, 128) and thespecific signal format that is used on the 10 Gb/s Ethernet Links (110)based on the 10GBASE-R standard.

Also provided in the standard for 10GBASE-R are definitions for devicecontrol using a “Management Data Input/Output” interface (MDIO). Themodules for device control (Control 124) shown in FIG. 1 arerepresentative of means for controlling the interface devices, throughtheir MDIO interfaces (not shown), and to communicate with other controlstructures (not shown) within the associated node.

The use of links based on the 10GBASE-R standard in environments wherepreviously SONET OC-192 links might have been considered, leads to asignificant cost reduction. Nevertheless, it is desirable to be able totransmit various types of link related information between the nodesinterconnected by 10GBASE-R links without encroaching on the packetbandwidth that is committed to user data.

An example of a feature commonly employed on optical links is monitoringof the bit error rate (BER). The 10GBASE-R standard protocol providesonly a rudimentary possibility for ongoing BER monitoring, for exampleby monitoring the correct appearance of the synchronization bits (syncbits, see FIGS. 44A-1 and 44A-2 of the standard). In the 10GBASE-R linksystem 100 of FIG. 1, such a feature would be controlled by the Controlblock 124 to monitor a BER detector in the receiving PCS device 122 of atransceiver 106 or 108, and report the result to the local controlstructure (not shown) within the associated node, and possibly to anetwork management system (not shown). Monitoring the correct appearanceof the synchronization bits (2 out of every 66 bits) and extrapolating aBER from this provides only a crude estimate of the true BER, because nobit errors in the other 64 out of 66 bits are detected.

Another example of a common optical network feature is digital opticalmonitoring (DOM) which may exist in a link system of the type shown inFIG. 1. DOM is used for monitoring the quality of the received opticalsignal. This information is then commonly reported to the local controlstructure (not shown) within the associated node.

Overhead capabilities in optical links based on SONET include BitInterleaved Parity (BIP for bit error monitoring), optical pathidentity, and other parameters embedded in the link overhead. Whileproviding a standard (the MDIO) and other means (DOM) for the localmonitoring of module and link performance, the 10GBASE-R standard, inthe interest of keeping the cost of such links at a minimum, does notprovide capabilities for transmitting link related information directlyto the other end of the link.

The 10GBASE-R standard does provide a protocol element for signaling alocal fault to the far end. This capability is intended to report acondition indicating an inability of the node to communicate, and is notsuitable for link monitoring.

To improve the suitability of 10GBASE-R links in optical networks, andto provide additional link related functions it becomes necessary todevelop a method and associated means to permit the insertion andextraction of additional information, compatibly with the 10GBASE-Rstandard protocol, without encroaching on the user data bandwidth, andwithout unduly increasing the cost of such links.

SUMMARY OF THE INVENTION

Therefore there is an object of the invention to provide a method anddevice for communicating additional information regarding 10Gb/sEthernet links, which would avoid or reduce the above noted problems ofthe prior art.

According to one aspect of the invention there is provided a transceiverbetween an Ethernet media access control (MAC) layer device and a 10Gb/s Ethernet link, comprising a physical coding sublayer (PCS)extension circuit for implementing an extended link monitoring channelfor said link for communicating link related information during idleperiods between user data packets.

The PCS extension circuit comprises means for initializing said extendedlink monitoring channel, and means for transmitting and receiving thelink related information. Beneficially, the PCS extension circuit has ameans for processing a 10 Gb/s Ethernet signal in the form of 64B/66Bblocks. The means for processing comprises means for determining idleblocks of the idle periods within said Ethernet signal and replacingselected idle blocks with extended link monitoring blocks, and means fordetermining extended link monitoring blocks within said Ethernet signaland replacing them with idle blocks. Conveniently, the PCS extensioncircuit is controlled by an external device for the purpose ofinitializing said extended link monitoring channel, and for insertingand extracting the link related information.

For the purpose of determining a bit error rate (BER) for the link, themeans for transmitting and receiving the link related informationcomprises means for generating a pseudo-random bit sequence (PRBS) andevaluating a received PRBS.

Advantageously, the link is a 10 GBASE-R Ethernet link of the IEEE 802.3Ethernet standard, wherein the link is an optical link. Additionally,the PCS extension circuit may comprise means for splitting the extendedlink monitoring channel into a number of virtual link monitoringchannels, each of the virtual link monitoring channels intended forcommunicating a different type of the link related information.

According to another aspect of the invention there is provided aphysical coding sublayer (PCS) extension circuit for a 10 Gb/s Ethernettransceiver, providing signal adaptation between an Ethernet mediaaccess control (MAC) layer device and a 10 Gb/s Ethernet link, the PCSextension circuit comprising means for implementing an extended linkmonitoring channel for said link for transmitting link relatedinformation during idle periods between user data packets. The PCSextension circuit comprises means for initializing said extended linkmonitoring channel, and means for transmitting and receiving the linkrelated information.

Specifically, the PCS extension circuit has means for processing anEthernet signal in the form of 64B/66B blocks. The means for processingcomprises means for determining idle blocks within said Ethernet signaland replacing selected idle blocks with extended link monitoring blocks,and means for means for determining extended link monitoring blockswithin said Ethernet signal and replacing them with idle blocks.

Conveniently, the PCS extension circuit is controlled by an externaldevice for the purpose of initializing said extended link monitoringchannel, and for inserting and extracting the link related information.For the purpose of determining a bit error rate (BER) for the link, themeans for transmitting and receiving the link related informationcomprises means for generating a pseudo-random bit sequence (PRBS) andevaluating a received PRBS.

Beneficially, the transceiver is designed for a 10 GBASE-R Ethernet linkof the IEEE 802.3 Ethernet standard, wherein the link is an opticallink. Conveniently, the PCS extension circuit further comprises meansfor splitting the extended link monitoring channel into a number ofvirtual link monitoring channels, each of the virtual link monitoringchannels intended for communicating a different type of the link relatedinformation.

According to yet another aspect of the invention there is provided anode in an a 10 Gb/s Ethernet network, comprising at least two nodesconnected by a 10 Gb/s Ethernet link, the node having a transceiverbetween an Ethernet media access control (MAC) layer device and the 10Gb/s Ethernet link, the transceiver comprising a physical codingsublayer (PCS) extension circuit for implementing an extended linkmonitoring channel for said link for transmitting link relatedinformation during idle periods between user data packets.

The PCS extension circuit within the transceiver at the node has a meansfor processing an Ethernet signal in the form of 64B/66B blocks, themeans for processing comprising means for determining idle blocks withinsaid Ethernet signal and replacing selected idle blocks with extendedlink monitoring blocks, and means for determining extended linkmonitoring blocks within said Ethernet signal and replacing them withidle blocks. Conveniently, the PCS extension circuit comprises means forgenerating a pseudo-random bit sequence (PRBS) to be sent through saidextended link monitoring channel, and evaluating a received PRBS for thepurpose of determining a bit error rate (BER) for the link. Acommunications network may comprise a plurality of nodes, at least twoof the connected nodes being the node of the type as described above.

According to one more aspect of the invention there is provided a methodfor implementing an extended link monitoring channel for a 10 Gb/sEthernet link carrying an Ethernet signal in the form of blocks of Nbits, the method comprising the step of communicating link monitoringinformation over said channel, wherein the step of communicatingcomprises determining idle blocks between blocks of user data andsubstituting selected idle blocks with extended link monitoring blocksincluding blocks to carry link related information and control blocksfor said channel. The step of substituting selected idle blocks withcontrol blocks for said channel comprises constructing said controlblocks according to the IEEE 802.3 Ethernet standard and using selectedreserved codes of the standard. Beneficially, the method is performedfor the Ethernet signal in the form of blocks of 66 bits according tothe IEEE 802.3 Ethernet standard for 10GBASE-R Ethernet links.

Beneficially, the method further comprises the step of initializing saidchannel, the step of initializing being performed before the step ofcommunicating, wherein the step of initializing comprises:

-   -   determining idle blocks between blocks of user data and        substituting selected idle blocks with ping blocks, which are a        type of the control blocks to be sent to the far end; and    -   receiving ping blocks from the far end.

The step of substituting with the ping blocks comprises substitutingwith ping blocks constructed with such selected reserved codes of theIEEE 802.3 Ethernet standard that, when received by a transceiver at thefar end which lacks the PCS extension circuit, the ping blocks will notbe recognized and interpreted as if they were idle blocks of thestandard. The step of substituting selected idle blocks with extendedlink monitoring blocks comprises substituting each of the selected idleblocks with one of the following types of the extended link monitoringblocks:

-   -   a Q-start block;    -   a channel data block; and    -   a Q-stop block,        wherein the Q-start block and Q-stop block are control blocks,        and the channel data block carries the link related information.

Advantageously, the step of initializing comprises:

-   -   substituting the selected idle blocks with the ping blocks to be        sent to the far end so that only each (N₁+1)-th idle block is        substituted with the ping block until a total of N_(x) ping        blocks has been substituted; and    -   receiving from the far end at least N_(R) ping blocks separated        by no more than N_(J) idle blocks, N_(R) being less or equal to        N_(X), and N_(J) being equal to or greater than N_(I).        Conveniently, N₁=16, N_(X)=16, N_(R)=8, N_(J)=32.

The step of communicating comprises substituting the selected idleblocks with a sequence of the Q-start block, zero or more of the channeldata blocks, and the Q-stop block, the sequence forming a linkmonitoring packet. The step of substituting with the Q-start blockcomprises substituting with the Q-start block having an identifier for avirtual link monitoring channel within said extended link monitoringchannel, the virtual link monitoring channel intended for communicatinga specific type of the link related information.

According to one more aspect of the invention there is provided anextended link monitoring channel for a 10 Gb/s Ethernet link extendingbetween a physical coding sublayer (PCS) devices for communicating linkrelated information during idle periods between user data packets, thelink related information being one or more of the following:

-   -   a pseudo random bit sequence (PRBS) for bit error rate        measurement;    -   data from a digital optical monitoring (DOM) subsystem for        monitoring optical link parameters;    -   information contained in registers of the PCS devices; and link        states and alarms.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example,with reference to the accompanying drawings in which:

FIG. 1 illustrates a typical optical communications system using 10 Gb/sEthernet links (10GBASE-R) according to the Ethernet 802.3 standard ofthe prior art;

FIG. 2 is a block diagram of a transceiver for improved 10GBASE-R linksaccording to an embodiment of the invention;

FIG. 3 shows the format of the 10GBASE-R signal at the 64B/66B interfaceaccording to the Ethernet 802.3 standard of the prior art;

FIGS. 4 a, b and c illustrate respectively, a time line (a), a diagramof a standard 10GBASE-R signal (b), and a diagram of a 10GBASE-R showingthe operation of the Extended Link Monitoring Channel of the embodimentof the invention (c);

FIGS. 5 a, b, c, and d show respectively, the formats of an idle blockof the prior art (a), of a Ping block (b), of a Q-Start block (c), andof a Q-Stop block (d) of the embodiment of the invention;

FIG. 6 illustrates a Transmit Handshake state diagram, showing part ofthe initialization protocol of the embodiment of the invention;

FIG. 7 illustrates a Receive Handshake state diagram, showing anotherpart of the initialization protocol of the embodiment of the invention;

FIG. 8 illustrates a state diagram of the Transmit Features Operation ofthe embodiment of the invention; and

FIG. 9 illustrates a state diagram of the Receive Features Operation ofthe embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENT OF THE INVENTION

An Extended Link Monitoring Channel has been developed to beincorporated in a 10GBASE-R link providing the capability to transmitinformation in addition to, and without affecting, the carriage of userdata packets. The Extended Link Monitoring Channel can be used toconduct exhaustive BER measurements over the link, transmit the resultsof Digital Optical Monitoring (DOM), or any other information. TheExtended L,ink Monitoring Channel requires enhancements to thetransceiver for 10GBASE-R, an initialization procedure to set up thechannel, and a transfer protocol for the use of the channel.

Transceiver

A transceiver 200 for an improved 10GBASE-R link having means forimplementing an Extended Link Monitoring Channel according to anembodiment of the invention, is shown in FIG. 2.

The transceiver 200 comprises a number of modules operating in both thetransmit direction and the receive direction between an electrical “10Gigabit Attachment Unit Interface” (XAUI) 202 and an optical “MediaDependent Interface” (MDI) 204. The transceiver 200 provides aconnection between an Ethernet media access control (MAC) layer device(interfaced at the XAUI 202) and a 10 Gb/s Ethernet link (interfaced atthe MDI 204) while simultaneously providing the Extended Link MonitoringChannel for communicating link related infonnation during idle periodsbetween user data packets. Details of the implementation will bedescribed in this and the following sections.

The modules include:

-   -   a “XGMII Extender Sublayer” module (XGXS) 206;    -   a “Physical Coding Sublayer” module (PCS) 208 including        -   a PCS 64B/66B Coder circuit 209,        -   a Quake PCS extension circuit 210, and        -   a PCS scrambler circuit 211; and    -   an Electro-Optical module (E/O) 212 providing the interface to        an optical link.

In addition, the transceiver 200 includes a control module 214 and aDigital Optical Monitoring module (DOM) 216.

Intermediate interfaces between the modules and the circuits are;

-   -   a “10 Gigabit Media Independent Interface” (XGMII) 218 between        the XGXS module 206 and the PCS module 208;    -   an internal interface 219 between the PCS 64B/66B Coder circuit        209 and the Quake PCS extension circuit 210 in the PCS module        208;    -   a second internal interface 220 between the Quake PCS extension        circuit 210 and the PCS scrambler circuit 211 in the PCS module        208;    -   a 64B/66B electrical interface 222 between the PCS module 208        and the E/O module 212;    -   MDIO interfaces 224 between the control module 214, and the XGXS        module 206 and the PCS 208 module;    -   a link 226 between the control module 214 and the DOM module        216; and    -   a link 228 between the DOM module 216 and the E/O module 212.

The XAUI interface 202, the XGMII interface 218, the 64B66B interface222, and the MDI interface 204 are described in detail in the standard.The internal interfaces 219 and 220 are conveniently similar to the64B/66B electrical interface 222, as described in the standard.

The modules 206 and 208 (containing circuits 209, 210, and 211) may begrouped into a single electrical data path device 230. It should beunderstood that the division of the embodiment of the data path device230 into modules, circuits, and interfaces is done to facilitate thedescription. This is especially convenient, since the standard providesa description of the XGMII 218. Further, the modules 206 and 208 may bemanufactured together in a single integrated circuit (the data pathdevice 230). In this case the interfaces 218, 219, and 220 are embeddedwithin the device 230, and not available outside the device.

In its basic operation (without the Extended Link Monitoring Channelenabled), the transceiver 200 converts received XAUI signal from theXAUI 202 into the 64B/66B signal at the interface 222, as well asconverting the 64B/66B signal from the interface 222 into the XAUIsignal at the XAUI 202, in the conventional manner prescribed by thestandard. The conversion occurs in two steps, through the XGXS module206 to convert the XAUI signal 202 to the XGMII signal at the interface218 (and the reverse), and through the PCS module 208 to convert theXGMII signal at the internal interface 218 to the 64B66B signal at theinterface 222 (and the reverse). Within the PCS module 208, conversionbetween the XGMII signal at the interface 218 and the 64B/66B signal atthe interface 222 includes two steps in the conventional mannerprescribed by the standard: through the PCS 64B/66B Coder circuit 209between the XGMII signal at the interface 218 and the internal interface219, and through the PCS scrambler circuit 211 between the secondinternal interface 219 and the 64B/66B signal at the interface 222. Whenthe Extended Link Monitoring Channel is not enabled, the Quake PCSextension circuit 210 simply passes the signal at the internal interface219 to the second internal interface 220 and vice versa.

A handshake protocol (see FIGS. 6 and 7 below for details) isimplemented in the Quake PCS extension circuit 210 in order toinitialize and thus enable the Extended Link Monitoring Channel

The means for implementing the Extended Link Monitoring Channel,including the functions of initializing the channel and for insertingand extracting the link related information, is the Quake PCS extensioncircuit 210 between the internal interface 219 and the second internalinterface 220. Briefly, when the Extended Link Monitoring Channel isenabled, the Quake PCS extension circuit 210 passes user data signals(Ethernet packets) transparently, but processes the idle signals betweenthe Ethernet packets (the Tnter Packet Gaps or IGPs) in a novel way toachieve the insertion and extraction of the Extended Link MonitoringChannel. The data inserted or extracted may be generated and received byfeature circuits (e.g. PRBS generation and monitoring) within the PCSmodule 208, or communicated to and from the Control module 214 over theMDIO interface 224. Applications of the Extended Link Monitoring Channelare described further below.

The 64B/66B signal at the interface 222 is converted to the opticalsignal at the MDI 204 by the E/O module 212 (and the reverse). The DOMmodule 216 comprises means for monitoring parameters of the E/O module212, such as the received optical power, and the optical transmittercurrent. In the preferred embodiment, the DOM contains an EEPROM(Electrically Erasable Programmable Read Only Memory) to store a historyof such parameters to facilitate their recovery and diagnosis after anoptical path failure.

The control module 214 has access to registers in the data path device230 via the standard MDIO interface 224, as well as to the results ofthe DOM 216 through the interface 226. The control module 214 isoperatively connected to the control system (not shown) of the node inwhich the transceiver 200 is located.

The Extended Link Monitoring Channel, through the means of the Quake PCSextension circuit 210, includes the ability for the control module 214to monitor the information stored in the DOM 216 and then transmit thisinformation via the MDIO interface 224 and the Quake PCS extensioncircuit 210 to the Control module 214 in a remote transceiver.

Similarly, a pattern generator (PRBS generator) may be included in theQuake PCS extension circuit 210. The Extended Link Monitoring Channelcan then be used to conduct BER tests over the optical link as will bedescribed in more detail below. The BER tests are controlled (functionenabled), and the results collected, by the Control module 214 throughthe MDIO interface 224.

In either case, the Quake PCS extension circuit 210 provides the meansfor initializing the Extended Link Monitoring Channel, and the means fortransmitting and receiving the link related information as described inthe next sections.

Basic 64B/66B Format

The format of the electrical Ethernet signal at the 64B/66B interface222 is shown in FIG. 3. This is also the format of the optical signalthat appears after electro/optical conversion at the MDI 204. The formatis described in the standard (clauses 44 and 49), but is summarized herefor convenience.

The transmitted data is a serial bit stream 300 consisting ofalternating Data Frame segments 302 and Inter Packet Gaps (IPG segments)304. Each Data Frame segment 302 carries an Ethernet packet (not shownin detail), and is comprised of a number (one or more) of Blocks 306.Because the length of Ethernet packets is variable, the length of eachData Frame segment 302, and thus the number of Blocks 306 is variableand depends on the length of the Ethernet packet.

Inter Packet Gaps 304 (the idle periods between user data packets) arealso comprised of Blocks 306. The number of Blocks 306 making up a DataFrame segment 302 or an IPG segment 304 is always an integer number,where the number of blocks in a Data Frame segment 302 depends on thelength of the Ethernet (user) packet, and the number of blocks in an IGPsegment 304 is at least one, and depends on the intensity of theEthernet packet traffic. When there are fewer or shorter Ethernetpackets to send, the length of the individual IGP segments 304 isincreased accordingly.

The IPG segments 304 also serve a function in clock justification, toprovide elasticity between the clock domains of the sending andreceiving node, i.e. blocks 306 of an IPG segment 304 can be dropped oradded as permitted by the standard to avoid overflow or underflow of thereceive packet buffer. However, no justification is required between asending PCS module 208 (including the Quake PCS extension circuit 210),and its receiving counterpart since the receiving circuitry in thesemodules derives its clock from the link that is driven at the clock rateof the transmitting PCS module 208. Clock justification (dropping orinserting extra IPG blocks as needed) is carried out in the XGXS module206, or at the XGMII interface 218, and is of no further interest here.

Each Block 306 is comprised of Sync Bits 308 and a Block Payload 310.The number of Sync Bits in each Block 306 is two. The Sync Bits have thebit values “10” if the block is a Data block (within a Data Frame 302).The bit values are “01” if the block is a Control block (part of anInter Packet Gap 304), a Start block 312 (first block) of a Data Frame302, or a Terminate block 314 (last block) of a Data Frame 302).

In general, Blocks 306 having the sync bit values “01” are termed“Control blocks”. Different types of control blocks are distinguishedfrom each other by the value of the first byte (the “Block Type Field”)of the block payload 310 (see section 49.2 “Physical Coding Sublayer(PCS)” of the standard).

Extended Link Monitoring Channel

Since each Data Frame 302 must be separated from the next Data Frame 302by an Inter Packet Gap (IPG) 304, a channel may be created by utilizingsome bandwidth within the Blocks 306 that make up the IPGs 304. Thischannel (the Extended Link Monitoring Channel) is created and accessedby the Quake PCS extension circuit 210 (FIG. 2) which is controlledthrough the MDIO interface 224. The Quake PCS extension circuit 210intercepts the data flowing between the internal interface 219 and thesecond internal interface 220, and is capable of modifying or replacingany Blocks 306 of IPGs (idle blocks) that occur.

An overview of the establishment (initialization) and the data transferoperation (communicating link related information) of the Extended LinkMonitoring Channel is shown in a timing diagram in FIG. 4.

There are three time lines drawn vertically in FIG. 4;

-   -   (a) a scale;    -   (b) a transmission sequence representative of a signal at the        internal interface 219; and    -   (c) a transmission sequence representative of a signal at the        second internal interface 220.

Each tick on the time line (a) represents one Block 306 (FIG. 3). Thetime line (b) shows a sequence of IPG segments (idle periods) 304 andData Frame segments (user data packets) 302, similar to FIG. 3. Theborders of the segments indicate the type of Block 306, as indicated bythe Sync Bits 308. Sync bit values of “10” are indicated by openrectangles (Data blocks), while solid black rectangles indicate sync bitvalues of “01” (Control blocks). Note that the possible appearance ofcontrol blocks (indicating errors) within the Data Frame segments 302 isignored here, for simplification.

Without the Extended Link Monitoring Channel, or if the Extended LinkMonitoring Channel is not enabled, the time line (b) is also the form ofthe signal that would be sent or received at the second internalinterface 220.

The time line (c) shows a sequence of IPGs 304 and Data Frames 302,interspersed with additional blocks and segments, representing theinitialization and operation of the Extended Link Monitoring Channel. APing block 402, is part of the handshake protocol (see FIGS. 6 and 7below) used to initialize the Extended Link Monitoring Channel. A LinkMonitoring Packet 404 is a sequence of a Q-Start block 406, a ChannelData segment 408 (a sequence of channel data blocks), and a Q-Stop block410. A sequence of one or more Link Monitoring Packets 404 comprises thetransfer protocol of the Extended Link Monitoring Channel.

The Ping block 402 as well as the Q-Start and Q-Stop blocks (406 and410) are special control blocks and have sync bit values of “01”(indicated by solid black rectangles). The Channel Data segment 408 hassync bit values of “10”, as indicated by the open rectangle.

It is worth noting here that the initialization and operation of theExtended Link Monitoring Channel, i.e. the transmission of the Pingblocks 402 and of Link Monitoring Packets 404 occurs during periods thatwould otherwise be occupied by IPG segments 304 (idle periods). Thetransmission of the user data packets (Data Frame segments 302) is notaffected. In other words, the idle periods between the user data packetsare used to establish and utilize the Extended Link Monitoring Channel.

Block Coding for the Extended Link Monitoring Channel

The Ping block 402 as well as the Q-Start and Q-Stop blocks (406 and410) need to be distinguished from ordinary IPG segments 304.

The standard (clause 49 of the standard) already provides a coding forthe blocks of the IPG segment 304. FIG. 5 illustrates the coding for theblocks of the IPG segment 304 (IPG block 502, also referred to as “idleblock”), and preferred specific encodings of the Blocks 306 for each ofthe cases of Ping (Ping block 402), Q-Start (Q-Start block 406), andQ-Stop (Q-Stop block 410).

Note that the description of the specific hexadecimal codes refers totheir values as they would appear at the second internal interface 220(before the scrambling that is mandated by the standard). The standardprovides the mapping of codes between the XAUI, XGMII, and 64B/66Binterfaces.

Each of the blocks 502, 402, 406, and 410 are 66-bit blocks, with thefirst two bits (sync bits 308) having the sync bit values “01”,indicating that the type of block (Control blocks). The remainder of theblock constitutes the block payload 310 (see FIG. 3).

Within the block payload 310, the first (8-bit) byte of each of theblocks 502, 402, 406, and 410 is a Block Type Field 510 having thehexadecimal value 0×1e. The remaining 56 bits ofthe block payload 310 ofeach of the blocks 502, 402, 406, and 410 are divided into eight 7-bitunits (“7-bit bytes”).

For the IPG block 502, the values of the eight 7-bit bytes areprescribed by the standard as 0×00.

The values for the Ping block 402 were selected from the reserved codesin Table 49-1 of the standard, so that they are automatically translatedinto idle codes if any of these blocks are received by a transceiverthat does not include the Extended Link Monitoring Channel describedhere.

As shown in FIG. 5, the first four of the 7-bit bytes have the value0×00. The fifth byte, a Block discriminator byte 512, is preferablyassigned the values 0×55 (Ping block), 0×69 (Q-Start block), and 0×70(Q-Stop block).

The remaining three 7-bit bytes have the value 0×55 in the Ping block402, and a set of possible feature code values (FCODE 514) in the casesof the Q-Start and Q-Stop blocks 406 and 410. The set of feature codevalues includes the (standard reserved) values 0×33, 0×66, and 0×78.Different combinations of these feature code values may be used toidentify different features for which a Channel Data segment 408 isused. The set of 3 values in three byte positions results in a total of27 possible different combinations, capable of identifying up to 27features. The combination of three feature code values FCODE 514 thatare present in a Q-Start block 406 or a Q-Stop block 410 is referred toas a “Function Code” 516. Preferably, the Function Codes 516 in theQ-Start block 406 and in the Q-Stop block 410 of a single LinkMonitoring Packet 404 are equal. Virtual Link Monitoring Channels aredistinguished by their Function Codes 516 in the Q-Start and Q-Stopblocks 406 and 410, each feature thus having a separate Virtual LinkMonitoring Channel available.

Note that, generally speaking, the method of initialization of theExtended Link Monitoring Channel and the method of communicating overthis channel, operate by transmitting extended link monitoring blocks(Ping blocks 402, Q-Start blocks 406, Q-Stop blocks 410, and plainchannel data blocks of the Channel Data segments 408) instead of(substituting for) idle blocks 502 between user data packets. Theencoding of the control blocks 402, 406, and 406, has been chosen usingreserved codes of the standard. Thus, at the receiving end, the distinctcodes of the extended link monitoring blocks enable these blocks to berecognized by the Quake PCS extension circuit, processed (initializationof the Extended Link Monitoring Channel and reception of the linkrelated information), and replaced by Idle blocks 502 before the signalis passed on to the XAUI 202.

At the same time, the encoding of the Ping block 402 has been chosen sothat a far end transceiver that lacks a Quake PCS Extension circuit doesnot fail, but absorbs any Ping blocks 402 it may receive as if they wereidle blocks (exploiting a feature of the standard which allows a numberof alternate idle codes to be present in the signal).

Extended Link Monitoring Channel Initialization

The use of the Extended Link Monitoring Channel requires that thetransceivers at both ends of a link are compatible and equipped with theQuake PCS extension circuit 210. A handshake of Ping blocks 402 is usedto confirm this. The block coding for Ping blocks 402 (see above) isdesigned to be safely ignored by a prior-art transceiver (a transceiverconforming to the existing standard but not containing the Extended LinkMonitoring Channel).

An initialization procedure at each end of a link relies on sending ahandshake sequence comprising N_(X) Ping blocks 402, each successivePing block 402 preceded by (and thus separated from the next Ping block402 by) N_(I). Idle blocks 502. At least N_(R) Ping blocks 402, spacedby no more than N_(J) Idle blocks 502 must be received by a transceiverto complete initialization. The values N_(I)=16, N_(X)=16, N_(R)=8, andN_(J)=32 have been selected in the preferred implementation of thealgorithm to ensure robust recognition by a compatible transceiver, andto minimize the risk of a non-compatible transceiver being falselyrecognized as compatible.

If an idle period (original IPG segment 304) is too short to insert acomplete handshake sequence, the counting of Idle blocks 502 and sendingof Ping blocks 402 is resumed in the next idle period.

The transceivers 200 (see FIG. 2) at each end of a link, acting astransmitters as well as receivers, must complete both handshakes for asuccessful initialization of the Extended Link Monitoring Channel. Themeans for executing the initialization procedure resides in the QuakePCS extension circuit 210 of each transceiver 200.

The initialization procedure is described as a pair of state diagrams, aTransmit Handshake 600 shown in FIG. 6, and a Receive Handshake 700shown in FIG. 7.

Transmit Handshake 600 (FIG. 6)

There are three states, a “TX IDLE” state T0, a “SENDING IDLE” state T1,and a “SENDING PING” state T2. The states are reached by statetransitions 606 into T0, 608 from T0 to T1, 610 from T1 to T2, 611 fromT2 to T1, and 612 from T2 to T0. The transitions are also labeled withthe signal, event, or condition which causes the transition to occur.

A number of control signals (originating in the Control module 214) areused:

-   -   “Reset”: Resets the device;    -   “Block Lock”: Reception of 64B/66B blocks is in sync;    -   “Quake Handshake Disable”: Disables the handshake        (initialization) procedure; and    -   “Quake Handshake Enable”: Enables the handshake (initialization)        procedure.

The Transmit Handshake 600 contains two counters:

-   -   a TX-Ping counter 602 to count the number of Ping blocks 402        sent; and    -   a TX-Idle counter 604 to count the number of Idle blocks 502        detected.

An event of relevance to the Transmit Handshake 600 is:

-   -   “Receiver enters R2 state”: This event is received from the        Receive Handshake 700 (see below).

The state T0 (TX IDLE) is entered (transition 606 to T0) when any of thefollowing occur:

-   -   the “Reset” signal is true (the device is reset);    -   the “Block Lock” signal is removed (block synchronization is        lost); or    -   the “Quake Handshake Disable” signal is or becomes true.

When in the T0 state, the Transmit Handshake 600 clears (sets to 0) theTX-Ping and TX-Idle counters 602 and 604.

The T1 state (SENDING IDLE) is first entered (transition 608 from T0 toT1) when either the “Quake Handshake Enable” signal becomes true or theReceive Handshake 700 enters the R2 state.

While in the T1 state, the Quake PCS extension circuit 210 of the datapath device 230 passes Idle blocks 502 received on the internalinterface 219 through to the second internal interface 220, incrementingthe TX-Idle counter 604 with each Idle block 502 detected and thus sent.It remains in the Ti state (loop marked “TX-Idle count <16″) as long asthe TX-Idle count remains under 16.

Once a TX-Idle count of 16 is reached, The next idle block is not passedthrough to the second internal interface 220, but a Ping block 402 issent instead. This is indicated by the transition 610 from T1 to theSENDING PING state T2. The TX-Ping counter 602 is incremented with eachPing block 402 sent.

If a TX-Ping count of 16 has not been reached, the Transmit Handshake600 returns to the SENDING IDLE state T1 (transition 611), and resetsthe TX-Idle counter 604 to zero.

Thus each Ping block 402 (sent upon the transition from the T1 state tothe T2 state) follows 16 Idle blocks 502.

Once a TX-Ping count of 16 has been reached, the Transmit Handshake 600is complete and returns to the TX IDLE state T0 (transition 612 from T2to T0).

The Transmit Handshake 600 operates only during the Idle Packet Gaps(IPG segments 304) and does not change state during the Data Frames 302.Thus, a number of IPG segments may be required to complete the TransmitHandshake 600, interrupted by Data Frames (user data packets) which arenot affected at all.

Receive Handshake 700 (FIG. 7)

There are three states, an “RX-IDLE” state R0, a “COUNTING” state R1,and a “QUAKE DETECTED” state R2. The states are reached by statetransitions 706 into R0, 708 from R0 to R1, 710 from R1 to R2, and 712from R1 to R0. The transitions are labeled with the signal, event, orcondition which causes the transition to occur.

Two control signals (originating in the Control module 214) are used:

-   -   “Reset”: Resets the device; and    -   “Block Lock”: Reception of 64B/66B blocks is in sync.

The Receive Handshake 700 also contains two counters:

-   -   an RX-Ping counter 702 to count the number of Ping blocks 402        received; and    -   an RX-Idle counter to count the number of Idle blocks 502        received.

An event of relevance to the Transmit Handshake 600 (FIG. 6 above) is:

-   -   “Receiver enters R2 state”: This event is sent to the Transmit        Handshake 600 when the Receive Handshake 700 has entered the R2        state from the R1 state. The event is the same as the transition        710 from R1 to R2.

The state R0 (RX-IDLE) is entered when either of the following occur:

-   -   the “Reset” signal is true (the device is reset); or    -   the “Block Lock” signal is removed (block synchronization is        lost).

When in the R0 state, the Receive Handshake 700 clears (sets to zero)the RX-Ping and RX-ldle counters 702 and 704.

The R1 state (COUNTING) is entered when a Ping block 402 is detected(transition 708 from R0 to R1).

While in the R1 state, the device counts the number of Idle blocks 502and Ping blocks 402 received by incrementing the RX-Idle and RX-Pingcounters 704 and 702 respectively. Each time a Ping block 402 isreceived, the RX-Idle counter 704 is reset to zero. In this way amaximum spacing rule (number of Idle blocks 502 between Ping blocks 402)is enforced.

The Receive Handshake 700 remains in the R1 state (COUNTING) as long asthe RX-Ping count remains at 8 or below, nd the RX-Idle count remains at32 or below (loop marked “RX-Ping count <=8) AND (RX-Idle count <=32)”).

When an RX-Ping count of 8 is exceeded, the transition 710 to the R2state (QUAKE DETECTED) occurs, and is sent as the event “Receiver entersR2 state” to the Transmit Handshake 600 above.

However, if an RX-Idle count of 32 is exceeded while the RX-Ping countis still at 8 or below, then a transition back to the R0 state(RX-IDI,E) is made, in effect indicating that the handshake has failed.

Extended Link Monitoring Channel Transfer Protocol

Once the Extended Link Monitoring Channel has been initialized betweentwo transceivers on a link, each transceiver can use this channel tosend arbitrary data to the other over the channel.

As shown in FIG. 4 above, the Link Monitoring Packet 404 is comprised ofthe Q-Start block 406, the Channel Data Segment 408, and the Q-Stopblock 410. This format provides a clear data channel in the form of abit-pipe that is carried transparently in the Channel Data Segment 408,allowing for additional protocols to be implemented within this channelin any convenient manner known in the art.

Furthermore, the coding of the Q-Start and Q-Stop blocks 406 and 410with Function Codes 516 provides for the distinction of a number (up to27) of different types of Link Monitoring Packet 404. This allows themultiplexing of a number of virtual Link Monitoring Channels over thesame link, effectively splitting the Extended Link Monitoring Channelinto a number of virtual Link Monitoring Channels, each intended forcommunicating a different type of link related information. As anexemplary use of this capability of the invention, the application of afeature is described.

A feature is a single mechanism requiring communication from onetransceiver to the other transceiver over the Extended Link MonitoringChannel on a 10GBASE-R link as described above. Several features canshare the Extended Link Monitoring Channel, i.e. each feature has accessto a separate Virtual Link Monitoring Channel.

One exemplary feature is the transmission of DOM data, or other datapertaining to link maintenance. This type of data could be relayed fromone node to another through a network management system over physicallydistinct control channels. In many cases however, especially when thedata is of the nature of, or related to, link failure alarms, it isuseful and desirable (much faster) to transmit this data directly fromnode to node before involving the management computers.

Another exemplary feature is the generation of a pseudo random bitsequence (PRBS) that is sent to the far end, and where the far endreceives the PRBS, compares it with a locally generated PRBS, and thusdetermines a bit error rate (BER) of the link. This method of BERmonitoring is common in the industry and is usually only possible whenthere is no user traffic on the link. The Extended Link MonitoringChannel of the invention provides a means to run PRBS-type BER testsduring the idle periods (IPGs) of a 10GBASE-R link, in effectcontinuously.

A transfer protocol for multiple features (“Quake features”) isdescribed with the help of state diagrams Transmit Features 800 andReceive Features 900 in FIGS. 8 and 9 respectively.

Each Quake Feature may be assigned a Function code 516 (corresponding toa defined set of three FCODES 514, see FIG. 5). When a Quake Feature isenabled, it shares the Extended Link Monitoring Channel of the inventionwith other enabled features, each Quake Feature having in effect aprivate clear data channel (a virtual Link Monitoring Channel) for itsuse. The Extended Link Monitoring Channel may also be described as amultiplexed channel, capable of carrying a number of virtual LinkMonitoring Channels.

Transmit Features

The Transmit Features 800 is shown in a state diagram in FIG. 8.

There are a number of states, a “TX Data IDLE” state TDO, a “Ready toTransmit Data” state TD1, and a plurality of “Function x in Progress”states TD2_x where “x” is the index of a Function code 516 ranging from1 to n (n being the number of available Function codes 516, n=27 in thepreferred embodiment).

In the interest of simplifying the description, the variable “x” is usedin the names of transitions, states, and functions (where x may be anyvalue from 1 to n), to show correspondence.

The states are reached by state transitions 802 into TD0, 804 from TD0to TD1, 806_x from TD1 to TD2_x, and 808_x from TD2_x to TD1. Thetransitions are also labeled with the signal, event, or condition whichcauses the transition to occur.

A number of control signals are used:

-   -   “Reset”: Resets the device;    -   “All Lock”: Indicates that both Clock sync (Phase Locked Loop        clock recovery) and Block Lock (see above) are achieved;    -   “Quake Handshake Disable”: Disables the handshake        (initialization) procedure, and thus precludes the transfer        protocol;    -   “Quake Part”: Determines that the far end transceiver is a        (compatible) Quake device;    -   “Function x Enable”: Command to enable the Quake Feature x;    -   “Function x Disable”: Command to disable the Quake Feature x;        and    -   “Function x Complete”: Signaling that Quake Feature x has        finished, where x is a number from 1 to n.

An event of relevance to the Transmit Features 800 is:

-   -   “Receiver enters R2 state”: Received from the Receive Handshake        700 of FIG. 7.

The state TD0 (TX Data IDLE) is entered (transition 802 to TD0) when anyof the following occur:

-   -   the “Reset” signal is or becomes true (device is reset);    -   the “All Lock” signal is removed (becomes false);    -   the “Quake Handshake Disable” signal is or becomes true; or    -   the “Quake Part” signal is false, i.e. the receiver has not        entered the R2 state (above).

When the “Receiver enters R2 state” event is received from the ReceiveHandshake 700, confirming the availability of the Extended LinkMonitoring Channel, the “Ready to Transmit Data” state TD1 is entered(transition 804).

While in the TD1 state, the Transmit Features 800 waits for commands toenable any of the available features (i.e. Virtual Link MonitoringChannels to carry feature data). An arbitration circuit (not shown)gives fair access to all features in turn when there is contention.

The transition 806_x to a corresponding TD2_x state occurs when one ofthe “Function x Enable” signal becomes active (x=1 to n), for examplethe “Function 1 Enable” signal triggers the transition 806_1 to theTD2_1 state.

While in the TD2_x state (x=1 to n), the device waits for an InterPacket Gap IPG 304 (see FIG. 3) to occur, then inserts a Link MonitoringPacket 404 as described above (FIG. 4) to carry data from the currentfeature. The index of Function codes 516 that are sent in the Q-Startblock 406 and Q-Stop block 410 of the Link Monitoring Packet 404 in theTD_x state must be equal to “x”, corresponding to the Function “x”.

As may frequently happen, the Link Monitoring Packet 404 must be stopped(Q-Stop block 410 inserted) before all required data have been sent. Inthis case the Function “x” is not complete, and continues to sendadditional Link Monitoring Packets 404 whenever IPGs 304 are available.

When the Function “x” has finished (signal “Function x Complete”), orwhen the Function “x” is disabled by the controller (command signal“Function x Disable”), the transition 808_x occurs, returning theTransmit Features 800 to the TD1 state “Ready to Transmit Data”.

Receive Features

The Receive Features 900 is shown in a state diagram in FIG. 9.

There are a number of states, an “RX Data IDLE” state RD0, a “Ready toReceive Data” state RD 1, and a plurality of “Receiving Data fromFunction x” states RD2_x where “x” is the index of a Function code 516ranging from 1 to n (n being the number of available Function codes 516,n=27 in the preferred embodiment).

In the interest of simplifying the description, the variable “x” is usedin the names of transitions, states, and functions (where x may be anyvalue from 1 to n), to show correspondence.

The states are reached by state transitions 902 into RD0, 904 from RD0to RD1, 906_x from RD 1 to RD2_x, and 908_x from RD2_x to RD1. Thetransitions are also labeled with the signal, event, or condition whichcauses the transition to occur.

A number of control signals are used:

-   -   “Reset”: Resets the device;    -   “All Lock”: Indicates that both Clock sync (Phase Locked Loop        clock recovery) and Block Lock are achieved;    -   “Quake Handshake Disable”: Disables the handshake        (initialization) procedure, and thus precludes the transfer        protocol; and    -   “Function x Enable”: Command to enable the Quake Feature x,        where x is a number from 1 to n.

Events of relevance to the Receive Features 900 are:

-   -   “Receiver enters R2 state”: Received from the Receive Handshake        700 of FIG. 7;    -   “Function x Start Detected”: Triggered when a Q-Start block 406        (FIG. 4 and 5) with a Function code 516 having the index value        “x” is received; and    -   “Function x Stop Detected”: Triggered when a Q-Stop block 410        (FIGS. 4 and 5) with a Function code 516 having the index value        “x” is received    -   “Control Block Detected”: Triggered when any Control block (Sync        bits value “01 “) is received.

The state RDO (RX Data IDLE) is entered (transition 902 to RDO) when anyof the following occur:

-   -   the “Reset” signal is or becomes true (device is reset);    -   the “All Lock” signal is removed (becomes false);    -   the “Quake Handshake Disable” signal is or becomes true.

When the “Receiver enters R2 state” event is received from the ReceiveHandshake 700, confirming the availability of the Extended LinkMonitoring Channel, the “Ready to Receive Data” state RD1 is entered(transition 904).

While in the RD1 state, the Receive Features 900 is responsive tocommands to enable any of the available features (i.e. Virtual LinkMonitoring Channels to carry feature data). The “Function x Enable”signals are preferably true by default, enabling all features to bereceived. Further, while in the RD1 state, the Receive Feature 900 waitsfor a Q-Start block 406 having any Function code 516 to be detected.

When a Q-Start block 406 with a Function code 516 having the index value“x” is received (the event “Function x Start detected”), the transition906_x to a corresponding RD2_x state “Receiving Data from Function x”occurs, but only if the “Function x Enable” command is not false (trueby default).

While in any of the RD2_x states, the device continues to receive data,in effect receiving a Link Monitoring Data Frame 302.

When the end of the Link Monitoring Data Frame 302 is reached, a Q-Stopblock 410 is expected, bearing the same Function code 516 having theindex value “x” as the previously received Q-Start block 406.

The detection of a Q-Stop block 410 triggers the transition 908_x fromthe RD2_x state to the “Ready to Receive Data” state RD1. The command“Function x Disable” also triggers the transition 908_x from the RD2_xstate to the RD1 state, canceling the feature even without a Q-Stopblock 410 having been received.

If, while in an RD2_x state, a Q-Stop block 410 with an incorrectFunction code 516 is detected, or indeed if any Control block, includingan IPG block 502, is detected, an error may have occurred and thetransition 908_x to the “Ready to Receive Data” state RD1 occurs.Depending on the type of feature “x” the error may be ignored, thereceived data may be discarded, or other action taken.

PRBS Feature

Bit Error Rate (BER) monitoring using a Pseudo Random Bit Sequence(PRBS) is an example of the application of the Extended Link MonitoringChannel.

It is common practice to generate a PRBS in a transmitting transceiver,and check it in the receiving transceiver of a link, as described above.

The Quake feature “PRBS” may be assigned the Function code (516) indexof 1, corresponding to the set of three FCODEs (514) {0×33, 0×33, 0×33},see FIG. 5.

Once initialization is complete (Transmit Handshake 600 and ReceiveHandshake 700), indicated by the “Receiver enters R2 state” event, theExtended Link Monitoring Channel is available for use. The “TransmitFeatures” 800 is now in the state TD1 (Ready to Transmit Data), and the“Receive Features” 900 is in the state RD1 (Ready to Receive Data).

Using the command “Function 1 Enable”, the Transmit Features 800 in thetransceiver 200 at the transmitting end of a link goes to the stateTD2_1, allowing the PRBS generator to send a pseudo random bit sequencein the Channel Data 408 field of a Link Monitoring Packet 404. TheQ-Start and Q-Stop blocks 406 and 410 of the Link Monitoring packet 404have the Function code (516) index value 1.

The PRBS transmission may continue as long as the Inter Packet Gap (IPG)permits, or may be terminated after a predetermined number of bits havebeen sent.

The Receive Feature 900 in the transceiver 200 at the receiving end ofthe link is waiting in the state RD1. Assuming the Function 1 isenabled, the Receive Feature 900 will detect the Q-Start block 406,having the Function code 516 index value of 1, and thus enter the stateRD2_1 (Receiving Data from Function 1) through the transition 906_1.

While in the state RD2_1, the Channel Data segment 408 with the PRBS isreceived and may be checked by the BER monitoring feature.

After the end of the Channel Data segment 408 a Q-Stop block 410 isdetected and the Receive Feature 900 leaves the RD2_1 state, to returnto the RD1 state (transition 908_1) and await another Q-Start block 406,with the same or perhaps a different Function code 516.

The Transmit Features 800 in the transceiver 200 at the transmitting endof a link may continue sending PRBS blocks in successive Link MonitoringPackets 404, whenever Inter Packet Gaps (IGPs) are available, and theReceive Feature 900 in the transceiver 200 at the receiving end of thelink may continue to receive and check the received sequences, thusproviding exhaustive BER monitoring. The same process may be occurringin both directions of the link simultaneously.

Other Features

The PRBS feature is only one example of a feature that is enabled by theExtended Link Monitoring Channel. The Digital Optical Digital OpticalMonitoring (DOM) is another feature. Many other useful features may beconceived, for example a feature to remotely retrieve register values(“read” the registers) from the transceiver at the far end, to monitor,enable, or disable link functions at the far end, and so on.

In general, two nodes interconnected by one or more 10 Gb/s Ethernetlinks equipped with transceivers 200 that provide the Extended LinkMonitoring Channel, are thus enabled to communicate link relatedinformation over these links. Similarly, in a communications networkcomprising such nodes, the availability of the Extended Link MonitoringChannel between network nodes enables the network to monitor its links(using the PRBS and the DOM feature) in a timely and efficient manner.

CONCLUSION

An Extended Link Monitoring Channel has been developed for 10GBASE-Rlinks that provides the capability to transmit information in additionto, and without affecting, the carriage of user data packets. TheExtended Link Monitoring Channel can be used to conduct exhaustive BERmeasurements over the link, transmit the results of Digital OpticalMonitoring (DOM), or send any other information. A robust initializationprotocol has been developed, along with a method for providing multiplevirtual Link Monitoring Channels for a plurality of features.

Through the added functionality provided by the Extended Link MonitoringChannel, the suitability of 10GBASE-R links in an optical network isimproved significantly, including the ability to insert and extract linkrelated information, in a way that is compatible with the 10GBASE-Rstandard protocol.

Although the embodiment of the invention has been described in detail,it will be apparent to one skilled in the art that variations andmodifications to the embodiment may be made within the scope of thefollowing claims.

1-33. (canceled)
 34. A system for communicating link monitoringinformation in an Ethernet network, the system comprising: a transceiverhaving an Ethernet interface to transceive Ethernet communications viaan Ethernet link, and a device interface; and, a physical codingsublayer (PCS) module interposed between the device and Ethernetinterfaces for inserting a link monitoring control channel intotransmitted Ethernet communications.
 35. The system of claim 34 whereinthe PCS module accepts Ethernet communications from the transceiverEthernet interface and recovers a link monitoring control channel. 36.The system of claim 35 wherein the PCS module accepts communicationsfrom the device interface, determines idle blocks in Ethernetcommunications to be transmitted, and replaces idle blocks with the linkmonitoring control channel.
 37. The system of claim 35 wherein the PCSmodule generates a pseudo-random bit sequence (PRBS) for the transmittedlink monitoring control channel, and evaluates a PRBS in the receivedlink monitoring control channel, for the purpose of determining anEthernet link bit error rate (BER).
 38. The system of claim 34 whereinthe PCS module inserts a plurality of link monitoring control channelsinto transmitted Ethernet communications, where each channel isassociated with a different link-related condition.
 39. The system ofclaim 34 wherein the PCS module inserts a link monitoring controlchannel for a purpose selected from a group consisting of monitoringBER, digital optical monitoring (DOM), bit interleaved parity (BIP),optical path identity, link states, alarms, and link far end localfaults.
 40. The system of claim 34 further comprising: a conversionmodule interposed between the PBS module and the device interface forconverting between Ethernet communications, in the form of 64B/66Bblocks, and a 10 gigabit Ethernet attachment unit interface (XAUI)signal on the device interface.
 41. The system of claim 35 furthercomprising: a control module having an interface connected to the PCSmodule for initializing the transmitted link monitoring control channel,and extracting Ethernet link-related information from the received linkmonitoring control channel.
 42. The system of claim 36 wherein the PCSmodule inserts the link monitoring control channel by substitutingselected idle blocks with link monitoring control channel blocksselected from a group consisting of a Q-start block, a channel datablock, a Q-stop block, and combinations of the above-mentioned blocks,wherein the Q-start block and Q-stop block are control blocks, and thechannel data block carries Ethernet link-related information.
 43. Thesystem of claim 36 wherein the PCS module substitutes selected idleblocks with the ping blocks in the transmitted link monitoring controlchannel so that only each (N_(l)+1)-th idle block is substituted with aping block until a total of N_(x) ping blocks has been substituted; and,wherein the PCS module receives the link monitoring control channel withat least N_(R) ping blocks separated by no more than N_(J) idle blocks,NR being less or equal to N_(x), and N_(J) being equal to or greaterthan N_(I).
 44. A method for communicating link monitoring informationin an Ethernet network, the method comprising: transceivingcommunications between an Ethernet link and a device interface; and,inserting a link monitoring control channel into transmitted Ethernetcommunications.
 45. The method of claim 44 further comprising:recovering a link monitoring control channel from received Ethernetcommunications.
 46. The method of claim 45 wherein inserting the linkmonitoring control channel into transmitted Ethernet communicationsincludes: accepting communications from the device interface;determining idle blocks in Ethernet communications to be transmitted;and, replacing idle blocks with the link monitoring control channel. 47.The method of claim 45 wherein inserting the link monitoring controlchannel into transmitted Ethernet communications includes generating apseudo-random bit sequence (PRBS) for the transmitted link monitoringcontrol channel; and, wherein recovering the link monitoring controlchannel from received Ethernet communications includes evaluating a PRBSin a received link monitoring control channel, for the purpose ofdetermining an Ethernet link bit error rate (BER).
 48. The method ofclaim 44 wherein inserting the link monitoring control channel intotransmitted Ethernet communications includes inserting a plurality oflink monitoring control channels into transmitted Ethernetcommunications, where each channel is associated with a differentlink-related condition.
 49. The method of claim 44 wherein inserting thelink monitoring control channel into transmitted Ethernet communicationsincludes inserting a link monitoring control channel for a purposeselected from a group consisting of monitoring BER, digital opticalmonitoring (DOM), bit interleaved parity (BIP), optical path identity,link states, alarms, and link far end local faults.
 50. The method ofclaim 44 further comprising: converting between Ethernet communications,in the form of 64B/66B blocks, and a 10 gigabit Ethernet attachment unitinterface (XAUI) signal on the device interface.
 51. The method of claim46 wherein replacing idle blocks with the link monitoring controlchannel includes substituting selected idle blocks with link monitoringcontrol channel blocks selected from a group consisting of a Q-startblock, a channel data block, a Q-stop block, and combinations of theabove-mentioned blocks, wherein the Q-start block and Q-stop block arecontrol blocks, and the channel data block carries Ethernet link-relatedinformation.
 52. The method of claim 46 wherein substituting selectedidle blocks includes substituting selected idle blocks with the pingblocks in the transmitted link monitoring control channel so that onlyeach (N_(l)+1)-th idle block is substituted with a ping block until atotal of N_(x) ping blocks has been substituted.
 53. The method of claim52 wherein recovering the link monitoring control channel from receivedEthernet communications includes receiving a link monitoring controlchannel with at least NR ping blocks separated by no more than N_(J)idle blocks, N_(R) being less or equal to N_(x), and N_(J) being equalto or greater than N_(I).